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Overview 


Session recording is a critical requirement in many communications 
environments, such as call centers and financial trading 
organizations. In some of these environments, all calls must be 
recorded for regulatory, compliance, and consumer-protection reasons. 
The recording of a session is typically performed by sending a copy 
of a media stream to a recording device. [RFC7865] focuses on the 
recording metadata that describes the Communication Session (CS). 
This document lists few examples and shows the snapshots of metadata 
sent from a Session Recording Client (SRC) to Session Recording 
Server (SRS). For the sake of simplicity, the entire Session 
Initiation Protocol (SIP) [RFC3261] messages are not shown, instead 
only snippets of the SIP and Session Description Protocol (SDP) 
[RFC4566] messages and the XML snapshot of metadata is shown. 


Terminology 


The terms used in this document are defined in [RFC7865] and 
[RFC6341]. No new definitions are introduced in this document. 


Metadata XML Instances 


The following subsections have examples that contain the metadata 
snapshot sent from the SRC to the SRS. 


Sample Call Flow 


The following is a sample call flow that shows the SRC establishing a 
Recording Session (RS) towards the SRS. In this example, the SRC 
could be part of any one of the architectures described in Section 3 
of [RFC7245]. 
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Figure 1: Sample Call Flow between SRC and SRS 
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For the sake of simplicity, ACKs to RE-INVITES and BYEs are not 
shown. The subsequent sections describe the snapshot of metadata 
sent from the SRC to the SRS for each of the above transactions (F1 
Fn-1). There may be multiple UPDATES/RE-INVITES mid call to 
indicate snapshots of different CS changes. Depending on the 
architecture described in Section 3 of [RFC7245], an SRC may be an 
endpoint, a B2BUA, or part of the MEDIACTRL architecture or the 
Conference focus. The subsequent sections in this document try to 
list some example metadata snapshots for three major categories. 


o The SRC recording streams unmixed to the SRS. This includes cases 
where the SRC is a SIP UA or B2BUA. 


o The SRC recording mixed streams to the SRS. This includes cases 
where the SRC is part of SIP conference model, as explained in 
[RFC4353]. 


o The SRC having a persistent RS with the SRS. 
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Oo Special flows like turret flows (used on financial trading floors 
to manage call activity). A trading turret is a specialized 
telephony key system that has a highly distributed switching 
architecture enabling parallel processing of calls. Figure 6 in 
Section 4 of [RFC6341] has the turret use case. 


Note that only those examples where metadata changes are listed in 
each category. For some of the call flows, the snapshots may be the 
same (like in case of endpoint or B2BUA acting as SRC) and the same 
is mentioned in the text preceding the example. 


3.2. Call Scenarios with SRC Recording Streams without Mixing 


This section describes example flows where SRC can be a SIP-UA or 
B2BUA as described in Section 3 of [RFC7245]. The SRS here can be a 
SIP-UA or an entity part of the MEDIACTRL architecture described in 
Section 3 of [RFC7245]. 


3.2.1. Example 1: Basic Call 


Basic call between two participants, Alice and Bob, who are part of 
the same CS. In this use case, each participant sends two media 
streams (audio and video). Media streams sent by each participant 
are received by the other participant in this use case. In this 
example, the SRC is a B2BUA in the path between Alice and Bob, as 
described in Section 3.1.1 of [RFC7245]. Below is the initial 
snapshot sent by SRC in the INVITE to SRS. This snapshot has the 
complete metadata. For the sake of simplicity, only snippets of SIP/ 
SDP are shown. In this example, the SRCs records the streams of each 
participant to SRS without mixing. 
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Metadata snapshot for CS setup: 
INVITE SRC -------------- > SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com; branch=z 9hG4bKdf 6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d83715d86 
; remote=00000000000000000000000000000000 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


-—-foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


m-video 49174 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:97 

a-sendonly 


m=audio 51372 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 
a-label:98 

a-sendonly 


m-video 49176 RIP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:99 
a-sendonly 
--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>complete</datamode> 
«group group_id="7+0TCyoxTmqmqyA/1weDAg=="> 

«associate-time»2010-12-16T23:41:07Z2«/associate-time» 

<!-- Standardized extension --» 

<call-center xmlns=’urn:ietf:params:xml:ns:callcenter’ > 
<supervisor>sip:alice@atlanta.com</supervisor> 

«/call-center» 

«mydata xmlns-'http://example.com/my'» 
«structure»FOO!«/structure» 
<whatever>bar</whatever> 

</mydata> 

</group> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
<sipSessionID>ab30317f1a784dc48f££824d0d3715d86; 
remote=47755a9de7794ba387653f2099600ef2</sipSessionID> 
<group-ref>7+0TCyoxTmqmqyA/ 1lweDAg== 

</group-ref> 

<!-- Standardized extension --» 

«mydata xmlns-'http://example.com/my'» 
«structure»FOO!«/structure» 
<whatever>bar</whatever> 

</mydata> 

</session> 
<participant 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 

«nameID aor="Sip:alice@atlanta.com"> 
«name xml:lang="it">Alice</name> 

</nameID> 

<!-- Standardized extension --» 

«mydata xmlns-'http://example.com/my'» 
«structure»FOO!«/structure» 
<whatever>bar</whatever> 

</mydata> 

</participant> 
<participant 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 

«nameID aor-"sip:bobGbiloxy.com"» 

«name xml:lang="it">Bob</name> 
</nameID> 

<!-- Standardized extension --» 

«mydata xmlns-'http://example.com/my'» 
«structure»FOO!«/structure» 
<whatever>bar</whatever> 

</mydata> 

</participant> 
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«stream stream id-"UAAMm5GROKSCMVvLyl4rFw--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
<label>96</label> 
</stream> 
«stream stream_id="i1lPz3to5hGk8fuxl+PbwCw==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
<label>97</label> 
</stream> 
«stream stream_id="8zc6e01YTIWIINA6GRt+3ag==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«label»98«/label» 
«/stream» 
«stream stream id-"EiXGlc-r4TruqqoDaNE76ag--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«label»99«/label» 
«/stream» 
<sessionrecordingassoc session id-"hVpd7YOgRW2nD22h7q60JgQ--2"» 
«associate-time»2010-12-16T23:41:07Z2«/associate-time» 
</sessionrecordingassoc> 
<participantsessionassoc 
participant_id="srfBElmCRp20B23b7Mpk0w==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«associate-time»2010-12-16T23:41:07Z2«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«associate-time»2010-12-16T23:41:07Z2«/associate-time» 
</participantsessionassoc> 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<send>ilPz3to5hGk8 fuXl1+PbwCw==</send> 
<send>UAAMm5GROKSCMVvLy14rFw==</send> 
<recv>8zc6e01YTIWIINA6GRt+3ag==</recv> 
<recv>EixGlct4TruqqoDaNE7 6ag==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>8zc6e01YTIWIINA6GRt+3ag==</send> 
<send>EixGlct+4TruqqoDaNE7 6ag==</send> 
<recv>UAAMm5GROKSCMVvLy14rFw==</recv> 
<recv>ilPz3to5hGk8 fuXl1+PbwCw==</recv> 
</participantstreamassoc> 
</recording> 
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3.2.2. Example 2: Hold/Resume 


A call between two participants Alice and Bob is established and an 
RS is created for recording, as in example 1. Bob puts Alice on hold 
and then resumes as part of the same CS. The 'send' and 'recv' XML 
elements of a 'participantstreamassoc' XML element is used to 
indicate whether or not a participant is contributing to a media 
stream. SRC sends a snapshot with only the changed XML elements. 


During hold 
Metadata snapshot for CS hold: 
RE-INVITE SRC-------------------- >SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 
; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


m-video 49174 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:97 

a-sendonly 


m=audio 51372 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 
a-label:98 

a-sendonly 
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m=video 49176 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:99 

a-sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version-"1.0" encoding-"UTF-8"?» 
«recording xmlns-'urn:ietf:params:xml:ns:recording:1'» 
«datamode»partial«/datamode» 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<recv>8zc6e01YTIWIINA6GRt+3ag==</recv> 
<recv>EixGlct4TruqqoDaNE7 6ag==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>8zc6e01YTIWIINA6GRt+3ag==</send> 
<send>EixGlct+4TruqqoDaNE7 6ag==</send> 
</participantstreamassoc> 
</recording> 


In the above snippet, Alice with participant_id 
SrfBElmCRp20B23b7Mpk0w-- only receives media streams and does not 
send any media. The same is indicated by the absence of a 'send' XML 
element. On the other hand, Bob (participant_id 
zSfPoSvdSDCmU3A3TRDxAw==) would be sending media, but he does not 
receive any media from Alice; therefore, the 'recv' XML element is 
absent in this instance. 


During resume 


The snapshot now has 'send' and 'recv' XML elements for both Alice 
and Bob, indicating that both are receiving and sending media. 
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Metadata snapshot for CS resume: 
RE-INVITE SRC-------------------- >SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: «sip:2000GQexample.com»;tag-235el195d2-9474d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 
; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a=label:96 

a=sendonly 


m=video 49174 RTP/AVPF 96 
a=rtpmap:96 H.264/90000 
a=label:97 

a=sendonly 


m=audio 51372 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 
a-label:98 

a-sendonly 


m-video 49176 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a=label:99 

a=sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<send>ilPz3to5hGk8 fuXl1+PbwCw==</send> 
<send>UAAMm5GROKSCMVvLy14rFw==</send> 
<recv>8zc6e01YTIWIINA6GRt+3ag==</recv> 
<recv>EixGlct4TruqqoDaNE7 6ag==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>8zc6e01YTIWIINA6GRt+3ag==</send> 
<send>EixGlct+4TruqqoDaNE7 6ag==</send> 
<recv>ilPz3to5hGk8 fuXl+PbwCw==</recv> 
<recv>UAAMm5GROKSCMVvLy14rFw==</recv> 
</participantstreamassoc> 
</recording> 


3.2.3. Example 3:Call Transfer (RE-INVITE and REFER Based) 


A basic call between two participants, Alice and Bob, is connected, 
and SRC (a B2BUA acting as SRC as per Section 3.1.1 of [RFC7245]) has 
sent a snapshot as described in example 1. Transfer is initiated by 
one of the participants (Alice). After the transfer is completed, 
the SRC sends a snapshot of the participant changes to the SRS. In 
this transfer scenario, Alice drops out after transfer is completed, 
Bob and Carol get connected, and recording of media between Bob and 
Carol is done by the SRC. There are two flows that can happen here 
as described below. 


Transfer within the same session (e.g., a RE-INVITE-based transfer): 
Alice drops out and Carol is added to the same session. No change to 
the session/group element is made. A 'participantsessassoc' XML 
element indicating that Alice has disassociated from the CS will be 
present in the snapshot. A new 'participant' XML element 
representing Carol with mapping to the same RS SDP stream used for 
mapping earlier Alice's stream is sent in the snapshot. A new 
'sipSessionID' XML element that has Universally Unique Identifier 
(UUID) tuples and that corresponds to Bob and Carol is sent in the 
snapshot from the SRC to the SRS. Note that one half of the session 
ID, that which corresponds to Bob, remains the same. 
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Metadata snapshot for INVITE based transfer in CS: 
RE-INVITE SRC-------------------- >SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 
; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


-—-foobar 
Content-Type: application/SDP 


m-audio 49180 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


m-video 49182 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:97 

a-sendonly 


m=audio 51374 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:98 

a-sendonly 


m-video 49178 RIP/AVPF 96 
a-rtpmap:96 H.264/90000 
a=label:99 
a=sendonly 
--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
<sipSessionID>3363127£0d084c10876dddd4f8e5eeb9 
; remote-2272bb7e70fe41dba0025ae9a26d54cf«/sipSessionID» 
</session> 
<participant 
participant id-"AtnmlZRnOC6Pm5MApkrDzQ--"» 
«nameID aor-"sip:carolGexample.com"» 
«name xml:lang="it">Carol</name> 
</nameID> 
</participant> 
<participantsessionassoc 
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«associate-time»2013-12-16T23:41:07Z2«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="srfBElmCRp20B23b7Mpk0w==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«disassociate-time»2013-12-16T23:41:07Z2«/disassociate-time» 
</participantsessionassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>8zc6e01YTIWIINA6GRt+3ag==</send> 
<send>EixGlct+4TruqqoDaNE7 6ag==</send> 
«recv»60JAJm9UTvikOLtlih/Gzw--«/recv» 
<recv>AcR5FUd3Edi 8cACQJy/3JQ==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant id-"AtnmlZRnOC6Pm5MApkrDzQ--"» 
«send»60JAJm9UTvikOLtlih/Gzw--«/send» 
«send»AcR5FUG3Edi8cACQJy/3JQ--«/send» 
<recv>8zc6e01YTIWIINA6GRt3ag==</recv> 
<recv>EixGlct4TruqqoDaNE7 6ag==</recv> 
«associate-time»2013-12-16T23:42:07Z2«/associate-time» 
</participantstreamassoc> 
</recording> 
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Transfer with a new session (e.g., REFER-based transfer): in this 
case, a new session (CS) is created and shall be part of same CS- 
group (done by the SRC). 


The SRC first sends an *optional* snapshot indicating disassociation 
of the participant from the old CS. An SRC may choose to just send 
an INVITE with a new 'session' XML element to implicitly indicate 
that the participants are now part of a different CS without sending 
disassociation from the old CS. In this example, the SRC uses the 
same RS. In case the SRC wishes to use a new RS, it will tear down 
the current RS using normal SIP procedures (BYE) with metadata, as in 
example 4. 


Metadata snapshot for REFER based transfer in CS: 
RE-INVITE SRC-------------------- >SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 
; remote-f81d4fae7dec11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m=audio 49180 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


m-video 49182 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:97 

a-sendonly 
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m=audio 51374 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 
a=label:98 

a=sendonly 


m=video 49178 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:99 

a-sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«stop-time»2010-12-16T23:41:07Z«/stop-time» 
</session> 
<participantsessionassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«disassociate-time»2010-12-16T23:41:07Z2«/disassociate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«disassociate-time»2010-12-16T23:41:07Z2«/disassociate-time» 
</participantsessionassoc> 
</recording> 


In the above snapshot, the 'participantsessionassoc' XML element is 
optional as indicating a 'session' XML element with a 'stop-time' XML 
element implicitly means that all the participants associated with 
that session have been disassociated. 


The SRC sends another snapshot to indicate the participant change 
(due to REFER) and new session information after transfer. In this 
example, it is assumed that the SRC uses the same RS to continue 
recording the call. The 'sipSessionID' XML element in the metadata 
snapshot now indicates Bob and Carol in the (local, remote) UUID 
pair. 
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Metadata snapshot for REFER based transfer in CS: 
RE-INVITE SRC-------------------- >SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: «sip:2000GQexample.com»;tag-235el195d2-9474d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 
; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m=audio 49180 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


m-video 49182 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:97 

a-sendonly 


m=audio 51374 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:98 

a-sendonly 


m-video 49178 RTP/AVPF 96 
a-rtpmap:96 H.264/90000 
a-label:99 

a-sendonly 


-—-foobar 
Content-Type: application/rs-metadata 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>complete</datamode> 
«session session id-"bfLZ-*NTFEeCNxQTuRyOBmw--"» 
<sipSessionID>3363127£0d084c10876dddd4f8e5eeb9 
; remote-2272bb7e70fe41dba0025ae9a26d54cf«/sipSessionID» 
«start-time»2010-12-16T23:41:07Z«/start-time» 
</session> 
<participant 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<nameID aor="sip:Bob@biloxy.com"/> 
</participant> 
<participant 
participant id-"AtnmlZRnOC6Pm5MApkrDzQ--"» 
«nameID aor="sip:carol@example.com"/> 
«/participant» 

«stream stream id-"60JAJm9UTvikOLtlih/Gzw--" 
session id-"bfLZ-*NTFEeCNxQTuRyOBmw--"» 
<label>96</label> 

</stream> 
«stream stream id-"ACR5FUG3Edi18cACQJy/3JQ--" 
session id-"bfLZ-*NTFEeCNxQTuRyOBmw--"» 
<label>97</label> 
</stream> 
«stream stream_id="8zc6e01YTIWIINA6GRt+3ag==" 
session_id="bfLZ+NTFEeCNxOQTuRyQBmw=="> 
<label>98</label> 
</stream> 
«stream stream_id="EHixGlc+4TruqqoDaNE7 6ag==" 
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> 
«label»99«/label» 
«/stream» 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session_id="bfLZ+NTFEeCNxQTuRyQBmw=="> 
«associate-time»2010-12-16T23:32:03Z«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant id-"Atnml1ZRnOC6Pm5MApkrDzQ--" 
session id-"bfLZ-*NTFEeCNxQTuRyOBmw--"» 
«associate-time»2010-12-16T23:41:07Z«/associate-time» 
</participantsessionassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>8zc6e01YTIWIINA6GRt+3ag==</send> 
<send>EixGlct+4TruqqoDaNE7 6ag==</send> 
«recv»60JAJm9UTvikOLtlih/Gzw--«/recv» 
<recv>AcR5FUd3Edi 8cACQJy/3JQ==</recv> 
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</participantstreamassoc> 
<participantstreamassoc 
participant id-"AtnmlZRnOC6Pm5MApkrDzQ--"» 
«send»60JAJm9UTvikOLtlih/Gzw--«/send» 
<send>AcR5FUd3Edi 8cACQJy/3JQ==</send> 
<recv>8zc6e01YTIWIINA6GRt+3ag==</recv> 
<recv>EixGlct+4TruqqoDaNE7 6ag==</recv> 
</participantstreamassoc> 
</recording> 


3.2.4. Example 4: Call Disconnect 


This example shows a snapshot of metadata sent by the SRC to the SRS 
when a CS with Alice and Bob as participants is disconnected. 


SRC SRS 


|(1) BYE (metadata snapshot) F1 


BYE sip:2001@example.com SIP/2.0 
Via: SIP/2.0/UDP src.example.com; branch=z9hG4bK47c8eb30 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: ab30317f1a784dc48ff824d0d3715d86 

; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 102 BYE 
Max-Forwards: 70 
Require: siprec 
Accept: application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


-—-foobar 
Content-Type: application/rs-metadata 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«stop-time»2010-12-16T23:41:07Z«/stop-time» 
</session> 
<participantsessionassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«disassociate-time»2010-12-16T23:41:07Z2«/disassociate-time» 
</participantsessionassoc> 


<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«disassociate-time»2010-12-16T23:41:07Z«/disassociate-time» 
</participantsessionassoc> 
</recording> 


3.3. Call Scenarios with SRC Recording Streams by Mixing 


This section describes a few example call flows where the SRC may be 
part of conference model either as focus or a participant in 
conference as explained in Section 3.1.5 of [RFC7245]. The SRS here 
can be a SIP User Agent (UA) or an entity part of the MEDIACTRL 
architecture. Note that the disconnect case is not shown since the 
metadata snapshot will be same as for a non-mixing case. 


3.3.1. Example 1: Basic Call with SRC Mixing Streams 


A basic call between two participants, Alice and Bob, who are part of 
one CS. In this use case, each participant calls into a conference 
server (say, a Multipoint Control Unit (MCU)) to attend one of many 
conferences hosted on or managed by that server. Media streams sent 
by each participant are received by all the other participants in the 
conference. Below is the initial snapshot sent by the SRC in the 
INVITE to the SRS that has the complete metadata. For the sake of 
simplicity, only snippets of SIP/SDP are shown. The SRC records the 
streams of each participant to SRS by mixing in this example. The 
SRC here is part of conference model described in Section 3 of 
[RFC7245] as a focus and does mixing. The SRC here is not a 
participant by itself and hence it does not contribute to media. 
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Metadata snapshot with the SRC mixing streams to the SRS: 
Fl INVITE SRC -------------- > SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: a358d2b81a444a8c8fb05950cef331e7 
; remote=00000000000000000000000000000000 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a=label:96 

a=sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>complete</datamode> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«sipSessionID»fa3b60f27e91441e84c55a9a0095£075 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e 
; remote=68caf509b9284b7ea45f84a04 9febf0a</sipSessionID> 
«start-time»2010-12-16T23:41:07Z«/start-time» 
</session> 
<participant 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
«nameID aor="Sip:alice@atlanta.com"> 
«name xml:lang="it">Alice</name> 
</nameID> 
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</participant> 
<participant 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<nameID aor-"sip:bobübiloxy.com"» 
<name xml:lang="it">Bob</name> 
</nameID> 
</participant> 
«stream stream id-"ilPz3to5hGk8fuXltPbwCw--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«label»96«/label» 
«/stream» 
<participantsessionassoc 
participant_id="srfBElmCRp20B23b7Mpk0w==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«associate-time»2010-12-16T23:41:07Z«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«associate-time»2010-12-16T23:41:07Z«/associate-time» 
</participantsessionassoc> 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<send>ilPz3to5hGk8 fuxX1+PbwCw==</send> 
<recv>ilPz3to5hGk8 fuxXl1+PbwCw==</recv> 
</participantstreamassoc> 


<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>i1lPz3to5hGk8 fuxX1+PbwCw==</send> 
<recv>ilPz3to5hGk8 fuxXl1+PbwCw==</recv> 
</participantstreamassoc> 
</recording> 


In the above example, there are two participants, Alice and Bob, in 
the conference. Among other things, the SRC sends Session-ID in the 
metadata snapshot. There are two Session-IDs here: one that 
corresponds to the SIP session between Alice and the Conference focus 
and the other for the SIP session between Bob and the Conference 
focus. In this use case, since Alice and Bob call into the 
conference, these Session-IDs are different. 
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Example 2: Hold/Resume with SRC Recording by Mixing Streams 


This is the continuation of example 1 (basic call with SRC mixing 
streams). A call between two participants, Alice and Bob, is 
established and an RS is created for recording, as in example 5. One 
of the participants, Bob, puts Alice on hold, and then resumes as 
part of the same CS. The 'send' and 'recv' XML elements of a 
'participant' XML element are used to indicate whether or not a 
participant is contributing to a media stream. The metadata snapshot 
is represented below: 


During hold 


Metadata snapshot when a CS participant goes on hold 
and the SRC is mixing the streams: 


RE-INVITE SRC -------------- » SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com; branch=z 9hG4bKdf 6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: a358d2b81a444a8c8fb05950cef331e7 
; remote-f81d4fae7dec11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
«stream stream id-"ilPz3to5hGk8fuXltPbwCw--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
<label>96</label> 
</stream> 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<recv>ilPz3to5hGk8 fuXl+PbwCw==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>ilPz3to5hGk8 fuXl1+PbwCw==</send> 
</participantstreamassoc> 
</recording> 


During resumption, a snapshot shown below will be sent from the SRC 
to the SRS. 


Metadata snapshot when a CS participant resumes and 
the SRC is mixing the streams: 


BEZINVITE SRC SSS SR Ss Se Ss > SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: a358d2b81a444a8c8fb05950cef331e7 
; remote-f81d4fae7dec11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 
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-—-foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version-"1.0" encoding-"UTF-8"?» 
«recording xmlns-'urn:ietf:params:xml:ns:recording:1'» 
«datamode»partial«/datamode» 
«stream stream id-"ilPz3to5hGk8fuXltPbwCw--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
<label>96</label> 
</stream> 
<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
«send»ilPz3to5hGk8fuXl-*PbwCw--«/send» 
<recv>ilPz3to5hGk8 fuXl1+PbwCw==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>ilPz3to5hGk8 fuX1+PbwCw==</send> 
<recv>ilPz3to5hGk8 fuX1+PbwCw==</recv> 
</participantstreamassoc> 
</recording> 


3.3.3. Example 3: Metadata Snapshot of Joining/Dropping of a 
Participant to a Session 


In a conference model, participants can join and drop a session any 
time during the session. Below is a snapshot sent from the SRC to 
the SRS in this case. Note the SRC here can be a focus or a 
participant in the conference. In the case where the SRC is a 
participant, it may learn the information required for metadata by 
subscribing to a conference event package [RFC4575]. Assume Alice 
and Bob were in the conference and a third participant (Carol) joins, 
then the SRC sends the below snapshot with the indication of new 
participant. 
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Metadata snapshot for a new participant joining CS: 
RE-INVITE SRC -------------- > SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com; branch=z 9hG4bKdf 6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: a358d2b81a444a8c8fb05950cef331e7 
; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


--foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a=label:96 

a=sendonly 


--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>partial</datamode> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«sipSessionID»fa3b60f27e91441e84c55a9a0095£075 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e 
; remote-68caf509b9284b7ea45f84a049febfÜa«/sipSessionID» 
<sipSessionID>497c0£13929643b4a16858e2a3885edc 
; remote=0e8a82bedda74f£57be4a4a4da54167c4</sipSessionID> 
</session> 
<participant 
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> 
«nameID aor-"sip:carolGexample.com"» 
«name xml:lang="it">Carol</name> 
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</nameID> 
</participant> 
<participantsessionassoc 
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
<associate-time>2013-12-16T23:41:072</associate-time> 
</participantsessionassoc> 
<participantstreamassoc 
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="> 
<send>ilPz3to5hGk8 fuXl1+PbwCw==</send> 
<recv>ilPz3to5hGk8 fuX1+PbwCw==</recv> 
</participantstreamassoc> 
</recording> 


After some time, Alice drops from the conference. The SRC generates 
a new snapshot showing Alice disassociating from the session. 


Metadata snapshot for a participant dropping from CS: 
RE-INVITE SRC -------------- > SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com; branch=z 9hG4bKdf 6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 

Session-ID: a358d2b81a444a8c8fb05950cef331e7 

; remote-f81d4fae7deci11d0a76500a0c91e6bf6 
CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/sdp, application/rs-metadata, 
application/rs-metadata-request 
Contact: «sip:20008src.example.com»;-*sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


-—-foobar 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 
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--foobar 
Content-Type: application/rs-metadata 
Content-Disposition: recording-session 


<?xml version-"1.0" encoding-"UTF-8"?» 
«recording xmlns-'urn:ietf:params:xml:ns:recording:1'» 
«datamode»partial«/datamode» 
«session session id-"hVpd7YOgRW2nD22h7q60JQ-2-2"» 
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e 
; remote=68caf509b9284b7ea45f84a04 9febf0a</sipSessionID> 
<sipSessionID>497c0£13929643b4a16858e2a3885edc 
; remote=0e8a82bedda74f£57be4a4a4da54167c4</sipSessionID> 
</session> 
<participantsessionassoc 
participant_id="srfBElmCRp20B23b7Mpk0w==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time> 
</participantsessionassoc> 
</recording> 


3.3.4. Example 4: Call Disconnect 


When a CS is disconnected, the SRC sends a BYE with a snapshot of 
metadata having a session stop time and participant disassociation 
times. The snapshot looks the same as listed in Section 3.2.4. 


3.4. Call Scenarios with Persistent RS between SRC and SRS 


This section shows the snapshots of metadata for the cases where a 
persistent RS exists between the SRC and the SRS. An SRC here may be 
a SIP UA or a B2BUA, or it may be part of a conference model as 
either the focus or a participant in a conference. The SRS here 
could be a SIP UA or an entity part of the MEDIACTRL architecture. 
Except in the disconnect case, the snapshot remains same as mentioned 
in previous sections. 
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.4.1. Example 1: Metadata Snapshot during CS Disconnect with 
Persistent RS between SRC and SRS 


Metadata snapshot for a CS disconnect with a persistent RS: 
RE-INVITE sent from SRC ----------- » SRS 


INVITE sip:2001@example.com SIP/2.0 
Via: SIP/2.0/UDP src.example.com; branch=z9hG4bK47c8eb30 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 

Session-ID: ab30317f1a784dc48ff824d0d3715d86 

; remote-f81d4fae7deci11d0a76500a0c91e6bf6 

CSeq: 101 INVITE 
Max-Forwards: 70 
Require: siprec 
Accept: application/rs-metadata, 
application/rs-metadata-request 
Contact: <sip:2000@src.example.com>;+sip.src 
Content-Type: multipart/mixed;boundary-foobar 
Content-Length: [length] 


-—-foobar 
Content-Type: application/rs-metadata 


<?xml version-"1.0" encoding-"UTF-8"?» 
«recording xmlns-'urn:ietf:params:xml:ns:recording:1'» 
«datamode»partial«/datamode» 
«session session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«stop-time»2010-12-16T23:41:07Z«/stop-time» 
</session> 
<participantsessionassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«disassociate-time»2010-12-16T23:41:07Z2«/disassociate-time» 
«/participantsessionassoc» 


<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«disassociate-time»2010-12-16T23:41:07Z«/disassociate-time» 
</participantsessionassoc> 
</recording> 


Ravindranath, et al. Informational [Page 29] 


RFC 8068 SIP Recording Call Flows February 2017 


3.5.  Turret-Case: Multiple CS into Single RS with Mixed Stream 


In trading-floor environments, in order to minimize storage and 
recording system resources, it may be preferable to mix multiple 
concurrent calls (each call is one CS) on different handsets/speakers 
on the same turret into a single RS. This would mean media in each 
CS is mixed and recorded as part of single media stream, and multiple 
such CSs are recording in one RS from an SRC to an SRS. 


Taking an example where there are two CSs [CS1 and CS2]: assume 
mixing is done in each of these CSs and both these CSs are recorded 
as part of single RS from a single SRC, which is part of both the 
CSs. There are three possibilities here: 


o CS1 and CS2 use the same focus for mixing, and that focus is also 
acting as SRC in each of the CSs. 


o One CS (e.g. CS1) SRC is the focus and the other CS (e.g. CS2), 
SRC is just one of the participants of the conference. 


o In both CS1 and CS2, the SRC is just a participant of conference. 


The following example shows the first possibility where CS1 and CS2 
use the same focus for mixing, and that focus is also acting as SRC 
in each of the CSs. 


Metadata snapshot with two CSs recorded as part of the same RS: 
INVITE SRC -------------- » SRS 


INVITE sip:recorder@example.com SIP/2.0 
Via: SIP/2.0/TCP src.example.com;branch-z9hG4bKdf6b622b648d9 
From: <sip:2000@example.com>; tag=35e195d2-947d-4585-946f-09839247 
To: <sip:recorder@example.com> 
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a 
Session-ID: a358d2b81a444a8c8fb05950cef331e7 
; remote-00000000000000000000000000000000 
Content-Type: application/SDP 


m-audio 49170 RTP/AVP O0 
a-rtpmap:0 PCMU/8000 
a-label:96 

a-sendonly 
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<?xml version="1.0" encoding-"UTF-8"?» 
«recording xmlns=’urn:ietf:params:xml:ns:recording:1’> 
<datamode>complete</datamode> 
«group group_id="7+0TCyoxTmqmaqyA/1weDAg=="> 
«associate-time»2010-12-16T23:41:07Z2«/associate-time» 
</group> 
«session session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«sipSessionID»fa3b60f27e91441e84c55a9a0095£075 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<sipSessionID>497c0£13929643b4a16858e2a3885edc 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<group-ref>7+0TCyoxTmqmqyA/1weDAg==</group-ref> 
«start-time»2010-12-16T23:41:07Z«/start-time» 
</session> 
«session session id-"e6370VVGEeWAG6886pl18uA--2"» 
<sipSessionID>ae10731ca50343a5aaae2dd0904a65de 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
«sipSessionID»33c77aac7deb414cbc8c10f363fccb71 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e 
; remote-a358d2b81a444a8c8fb05950cef331e7«/sipSessionID» 
<group-ref>7+0TCyoxTmqmqyA/ 1weDAg==</group-ref> 
«start-time»2010-12-16T23:43:07Z«/start-time» 
</session> 
<participant 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
«nameID aor="Sip:alice@atlanta.com"> 
«name xml:lang="it">Alice</name> 
</nameID> 
</participant> 
<participant 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
«nameID aor="sip:Bob@biloxy.com"> 
<name xml:lang="it">Bob</name> 
</nameID> 
</participant> 
<participant 
participant_id="EixGlct+4TruqqoDaNE7 6ag=="> 
«nameID aor="sip:Carol@example.com"> 
<name xml:lang="it">Carol</name> 
</nameID> 
</participant> 
«stream stream id-"UAAMm5GROKSCMVvLyl4rFw--" 
session id-"hVpd7YOgRW2nD22h7q60JgQ-2-2"'» 
<label>96</label> 
</stream> 


Ravindranath, et al. Informational [Page 31] 


RFC 8068 SIP Recording Call Flows February 2017 


<participantsessionassoc 
participant_id="srfBElmCRp20B23b7Mpk0w==" 
session_id="hVpd7YQgRW2nD22h7q60JQ=="> 
«associate-time»2010-12-16T23:41:07Z«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session id-"hVpd7YOgRW2nD22h7q60JQ--"» 
«associate-time»2010-12-16T23:41:07Z«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw==" 
session_id="e6370VVGEeEWAG6886p1 8uA=="> 
«associate-time»2010-12-16T23:43:07Z2«/associate-time» 
</participantsessionassoc> 
<participantsessionassoc 
participant id-"EiXGlc-t4TruqqoDaNE76ag--" 
session id-2"e6370VVGEeWAG6886pl18uA--"» 
«associate-time»2010-12-16T23:43:07Z2«/associate-time» 
</participantsessionassoc> 


<participantstreamassoc 
participant id-"srfBElmCRp20B23b7Mpk0w--"» 
<send>UAAMm5GROKSCMVvLy14rFw==</send> 
<recv>UAAMm5GROKSCMVvLy14rFw==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="> 
<send>UAAMm5GROKSCMVvLy14rFw==</send> 
<recv>UAAMm5GROKSCMVvLy14rFw==</recv> 
</participantstreamassoc> 
<participantstreamassoc 
participant_id="EixGlct+4TruqqoDaNE7 6ag=="> 
<send>UAAMm5GROKSCMVvLy14rFw==</send> 
<recv>UAAMm5GROKSCMVvLy14rFw==</recv> 
</participantstreamassoc> 
</recording> 


4. Security Considerations 
Security and privacy considerations mentioned in [RFC7865] and 
[RFC7866] have to be followed by the SRC and the SRS for setting up 
RS SIP dialogs and sending metadata. 

5. IANA Considerations 


This document does not require any IANA actions. 
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